app/composables/useGlobalSearch.ts (1)

60-67: Consider extracting focused input detection into a reusable helper.

The logic for detecting whether a search input is focused (lines 60-67) duplicates the pattern from getFocusedSearchInputValue (lines 22-24). Extracting a small isSearchInputFocused() helper would improve maintainability.

♻️ Proposed refactor

+const isSearchInputFocused = (): boolean => {
+  if (!import.meta.client) return false
+  const active = document.activeElement
+  if (!(active instanceof HTMLInputElement)) return false
+  return active.type === 'search' || active.name === 'q'
+}
+
 const getFocusedSearchInputValue = () => {
-  if (!import.meta.client) return ''
-
-  const active = document.activeElement
-  if (!(active instanceof HTMLInputElement)) return ''
-  if (active.type !== 'search' && active.name !== 'q') return ''
-  return active.value
+  if (!isSearchInputFocused()) return ''
+  return (document.activeElement as HTMLInputElement).value
 }

Then in the watcher:

-     if (import.meta.client) {
-       const active = document.activeElement
-       if (
-         active instanceof HTMLInputElement &&
-         (active.type === 'search' || active.name === 'q')
-       ) {
-         return
-       }
-     }
+     if (isSearchInputFocused()) return

app/composables/useGlobalSearch.ts (2)

65-73: ⚠️ Potential issue | 🟠 Major

Do not permanently drop focused URL synchronisation.

This early return also ignores legitimate /search?q=... history or programmatic changes while the input stays focused, leaving searchQuery and committedSearchQuery stale. Please distinguish self-initiated pending URL updates from external route changes, or queue a resync when the focused input blurs.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/composables/useGlobalSearch.ts` around lines 65 - 73, The current early
return in useGlobalSearch that checks document.activeElement prevents handling
legitimate external route/query changes; instead of unconditionally returning in
the focused-input branch, only suppress updates that are self-initiated (e.g.
compare the incoming route.query.q to a pending/last-synced value or to
committedSearchQuery) and allow external changes to update searchQuery and
committedSearchQuery; if the input is focused and the change is external, queue
a resync to apply the new query on blur by attaching a one-time blur handler
that will set searchQuery/committedSearchQuery to the route q, and add a small
pending flag (or lastSyncedQuery) to differentiate programmatic/self updates
from external route changes.

---

141-174: ⚠️ Potential issue | 🟠 Major

Guard mounted recovery after an intentional home reset.

The /search → / reset can be undone if onMounted reads the still-focused header input before the cleared model reaches the DOM. Add a one-shot shared guard so the same navigation that clears the home search cannot immediately restore the stale query.

Suggested guard shape

+  const skipFocusedRecovery = useState('skip-focused-search-recovery', () => false)
+
   if (import.meta.client) {
     watch(
       () => route.name,
       name => {
         if (name !== 'index') return
+        skipFocusedRecovery.value = true
         searchQuery.value = ''
         committedSearchQuery.value = ''
         // Use nextTick so we run after the homepage has rendered.
         nextTick(() => {
@@
   if (import.meta.client) {
     onMounted(() => {
+      if (skipFocusedRecovery.value && route.name === 'index') {
+        skipFocusedRecovery.value = false
+        return
+      }
+
       const focusedInputValue = getFocusedSearchInputValue()
       if (!focusedInputValue) return
       if (searchQuery.value) return

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/composables/useGlobalSearch.ts` around lines 141 - 174, Introduce a
one-shot guard ref (e.g., recentlyResetHome) shared between the route watch
block and onMounted so the intentional home reset cannot be immediately undone:
create a ref flag (recentlyResetHome) default false, set it to true inside the
watch handler right when you clear searchQuery/committedSearchQuery (before
calling nextTick), and in the onMounted block check if recentlyResetHome.value
is true — if so clear the flag and return early instead of restoring from
getFocusedSearchInputValue; optionally clear the flag after the nextTick in the
watch so it only prevents a single immediate restoration.

app/composables/useGlobalSearch.ts (1)

10-183: Split the client-only search lifecycle concerns.

useGlobalSearch now owns provider selection, URL sync, debounce control, homepage focus reset, and hydration recovery in one large function. Consider extracting the homepage reset and hydration recovery watchers into small helpers to reduce future state-sync regressions. As per coding guidelines, “Keep functions focused and manageable (generally under 50 lines)”.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/composables/useGlobalSearch.ts` around lines 10 - 183, The
useGlobalSearch function is doing too much; extract the homepage-reset watcher
and the hydration recovery onMounted logic into two small helper functions to
keep responsibilities separated: create (1) resetHomeSearchOnNavigate which
contains the watch on route.name that clears searchQuery and
committedSearchQuery and focuses/selects the `#home-search` input (using nextTick)
and is registered only when import.meta.client, and (2)
recoverFocusedInputOnMount which contains the onMounted block that reads
getFocusedSearchInputValue and sets searchQueryValue when appropriate; call both
helpers from useGlobalSearch in place of the inlined blocks and keep all
existing uses of searchQuery, committedSearchQuery, searchQueryValue,
getFocusedSearchInputValue, and flushUpdateUrlQuery unchanged.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

app/composables/useGlobalSearch.ts (1)

169-182: Hydration recovery logic is sound; one small note on duplicated registration.

The three-layer guard (pagesWithLocalFilter → !focusedInputValue → searchQuery.value) correctly prevents both page-local leakage and clobbering the intentional home reset: on /search → /, even if onMounted fires before the flush: 'post' route watcher, searchQuery.value is still the pre-reset value and the early return kicks in.

One minor observation (applies to both this onMounted and the watcher at lines 149‑167): because useGlobalSearch() is called by both the layout-level Header/SearchBox and page components (e.g. index.vue), each callsite registers its own onMounted / route.name watcher. On navigation to /, the reset-and-refocus path therefore runs twice. It is harmless (idempotent reset, focus on already-focused element) but slightly wasteful — optional to scope via the existing place parameter if you want to clean this up later.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/composables/useGlobalSearch.ts` around lines 169 - 182, Duplicate
onMounted/route watcher registrations occur because useGlobalSearch() is invoked
from multiple callsites (e.g., Header/SearchBox and page components); to avoid
the duplicate reset/refocus path, scope the registration using the existing
place parameter (or a per-instance guard) so the onMounted and the route.name
watcher only register in one place (e.g., when place === 'header' or place ===
'layout'), referencing useGlobalSearch, the onMounted block, the route watcher,
pagesWithLocalFilter, and searchQueryValue to locate the code to change; update
the conditional so only the intended instance registers the hydration recovery
logic.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes